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(54) Mettiod and system for out-tasking conversions of message attachments 



(57) A method and system for exchanging elec- 
tronic messages, such as email messages, include iso- 
lating personal computers and other client devices from 
the process of converting a message attachment from 
one file format to a second fae format File-fonrat con- 
versions are out-tasked to enhance file aocessbility. 
free computer resources, and conserve a user's tima 
The access requirements of each attachment to elec- 
tronic messages are conpared to the capat>ilities of a 
target client device, tf it is determined that a file-format 
conversion is required, the conversion operation is 
assigned to a server that supports the process of refor- 
matting the attachments. In an email environment the 
sender is substantiaQy equivalent to the conventional 
email server, txrt includes enhanced conversion capa- 
bilities, tn one embodment the determination of 
whether an attachment is accessible without conversion 
occurs at the server level. In another embodiment, the 
determination Is implemented at the client device level. 
Preferably, if a local email server is incapable of refor- 
matting the attachnwrtt a request is tmnsmitted to a 
remote server to perform the conversion. Typically, the 
remote server is the email server that supports mes- 
sage exchanges for the person who originated the mes- 
sage. 
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Description 

BACKGROUND OF THE INVENTION 

[0001] The invention relates generally to message s 
delivery systems and more particularly to methods and 
systems for providing compatibility between file attach- 
ments of the messages and resource capabilities of 
devices to which the messages are directed. 

10 

DESCRIPTION OF THE RELATED ART 

[0002] Systems that support the exchange of text 
messages among users often allow files to be attached 
to messages. As one exanple. electronic mail (i.e.. is 
email) may have an attachment that is a word process- 
ing document, or an audio, video or graphics file. As 
another example, a download of a message from a web 
site on the World Wide Web may include an attached 
text file in Hypertext Markup Language (HTML) or an 20 
attached audio, video or graphics file. 
[0003] Messages may be transmitted from a sending 
client device (such as a computer) or from a remote 
sender (such as a web server) to a message transport 
server that supports a computer or other client device at 25 
which the receiving party attempts to access the mes- 
sage. In an email environment, a sending party may 
generate an email message at a first computer that 
transmits the message to a first email server, tf the first 
email server does not support message access for the 30 
party to whom the message is directed, the first email 
server fonvards the message to a second email server 
that supports access by the receiving party. The mes- 
sage is stored at the second server for download by the 
receiving party. 

[0004] Such message exchange systems operate 
seamlessly for messages that do not include file attach- 
ments, since the systems are designed for sending 
enr^edded text Email is basically an ASCII text system. 
Difficulties arise when a message includes an attached 4o 
file. Seamless access to the attached file nr^y be inhib- 
ited by decoding-spedfic requirements or application- 
specific requirements upon the receiving client device. 
Regarding the decoding-specific requirements, 
attached files are typically encoded to accommodate 45 
transmission within a networK such as the Intemet. 
There are different available protocols for accomplishing 
the encoding. One such protocol is Multimedia Intemet 
Mail Extensions (MIME), which converts the attached 
files to text and sends the converted text within the mes- so 
sage. The converted text Is then reconverted to its orig- 
inal form at the receiving client device. Other well known 
standards include UUencode and BinHex. At the receiv- 
ing client device, the same encoding standard must be 
used to decode the attached file, if the file is to be ss 
accessed. 

[0005] Even if the attached file is properly decoded at 
the receiving client device, the file will not be accessible 
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unless the client device has the required application 
program for opening the attached file. Typically, an 
attachment has a file format that is specific to an appli- 
cation. For example, an email attachment of a word 
processing text file may be specific to a particular word 
processing program. Access to the text is possible only 
if the receiving client device includes the program or has 
the capability of converting the decoded file to another 
file fomnat that is accessitde. Video, audio and graphics 
files typically have more exacting demands. For exam- 
ple, an AVI video formatted file is not converted to a 
MPEG video fomnatted fOe without significantly more 
complexity than the process of converting from one 
application-specific word processing file format to a sec- 
ond application-specific word processing file format. 
[0006] Many client devices have the capability of con- 
verting attachments from a limited number of inaccessi- 
ble file formats to an acceptable file format. If the 
attachment is a relatively short word processing docu- 
ment, this capability is all that is required for efficient 
display of the document at the receiving client device. 
However, if the attached file is large, such as an intra- 
corporation multimedia presentation of a new product 
release, the required time to convert the attachment 
between file formats may lead to a significant inefficient 
use of the time of corporate personnel. Particularly in 
the conversion of multimedia file attachments, a com- 
plex algorithm must be utilized. 
[0007] Thus, if a file attachment is received that 
requires an application that is "foreign" to the receiving 
computing device, the first issue is whether the comput- 
ing device is capable of converting the attachment to an 
accessible file format A second issue relates to the time 
requirements of the conversion process, if a conversion 
is executable. A third issue relates to the reliability of the 
conversion operation. Often, the conversion causes 
data loss. 

[0008] What is needed is a messaging method and 
system that provide an efficient and reliable exchange 
of attached files in a nulti-appllcation environment 

SUMMARY OF THE INVENTION 

[0009] A method and system for exchanging elec- 
tronic messages, such as email messages, include out- 
tasking conversions of file formats when it is determined 
that a client device does not include the resources to 
directly access an attachment without conversion. The 
access requirements of each attachment to electronic 
messages are compared to the capabilities of the client 
device to which the attachment is to be transfenred. If it 
is determined that a file-format conversion is required, 
the conversion operation is assigned to a server that 
supports the process of reformatting the attachment In 
an email environment, the server may be substantially 
equivalent to the conventional email server, but includes 
enhanced conversion capabilities. 
[0010] In one embodiment the detemiination of 
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whether an attachment is acx;es8ible without conversion 
by a target client device occurs at the server. One 
means of enabling the server to execute the determina- 
tion Is to maintain a universal register of applications at 
the sender. The universal register may be a lookup table 
that Identifies each application program stored at each 
client device supported by the server. The lookup table 
may also include data that matches each user (i.e., 
potential recipient) with a client device at which the user 
typically accesses messages (e.g., a target computer). 
When a message is received at the sender, the file for- 
mal of any attachment is identified. In its simplest fbmn, 
this is accomplished by looking at the file extension 
(e.g.. .BMP identifies a bitmap graphics fomiat and 
.MPEG indicates a specific video fonnat). Alternativety. 
the format indicator may be embedded by the sending 
party vnthin the message that includes the attachment. 
As a third possibility, the server may access each 
attachment in order to identify its file format. If a file-for- 
mat conversion is necessary, the conversion can be 
implemented at the server, thereby freeing resources 
and processing time at the target client device. In this 
embodiment, the conversion may be transparent to the 
receiving party. 

[0011] In another embodiment, the detemnination of 
whether an attachment is accessible without conversion 
occurs at the target client device. Conventionally, com- 
puters include a register of applications that are stored 
in memory. Such an application register may be used to 
automatically check attachment accessibility. If the cli- 
ent device is unable to access the attachment without 
conversion, a request may be transmitted to the sender 
to perform the conversion. Many server protocols allow 
messages to be left on the server for a period of time 
after a download to a target client device (e.g.. Post 
Office Protocol-POP3). Thus, it is not necessary to 
upload the attachment in order to allow the conversion 
at the server. Following the conversion to a directly 
accessible ffle format the attachment is again down- 
loaded to the target client devica 
[001 2] The out-tasking of ttie conversion operation to 
the local server may be utilized even if the target client 
device is capable of the file-format conversion. By exe- 
cuting the conversion at the server, the process is com- 
pleted off-line witti respect to the user and the user's 
client device. This frees the resources of the client 
device to perform other tasks and often saves time for 
the user. 

[0013] However, if neither the client device nor ttie 
local sender is capable of performing the necessary con- 
version to allow file access by the target client device, 
the invention preferably includes a step of transmitting a 
request to a remote server to perform the conversion. 
Typically, the remote server is the message server that 
supports the exchange of messages for the person who 
originated the message having the attachment that 
requires conversion. In another embodiment, the server 
is maintained by an independent entity. For occasions in 



which the remote server is capable of converting the 
attachment the format-converted f ile is returned to the 
local server for access by the recipient user. On the 
other hand, if the remote server cannot perform the con- 
5 version, the conversion request may be passed to the 
sending client device, attempting to trigger an automatic 
conversion and/or notifying the sender that this attach- 
ment was not accessed by the intended receiver. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 
[0014] 

Rg. 1 is a schematic view of one embodiment of a 
15 message exchange system ttiat provides file-format 
conversion in accordance with the invention. 
Rg. 2 is a process flow of one enr^odiment for car- 
rying out the conversion process in the system of 
Rg. 1. 

20 Rg. 3 is a second embodiment of a conversion 
process in accordance with the invention. 

DETAILED DESCRIPTION 

25 [001 5] With reference to Rg. 1 , a messaging system 
10 is shown as including a local router/server 12 for 
supporting access to stored messages by a number of 
client devices 14, 16 and 18. The routing operations of 
the router/sender 12 are not the primary focus of the 

30 messaging system and method. Therefore, the 
router/sender will be idoitified primarily as ttie local 
server. The structure of the server is not critical to the 
invention. Conventional message servers are used to 
store received messages and to provide access to the 

35 Stored messages upon verification of a user klentity. 
Such identification generally requires input of a pass- 
word that is specific to the user. 
[0016] The messaging system 10 may be used to 
exchange messages of any one of a variety of message 

40 types. For example, the messages may be downloads 
from a web site of the World Wide Web, so ttiat a link 20 
to a network 22 is a connection to the global communi- 
cations network refened to as the Intemet. However, ttie 
system and mettiod will be described primarily witti 

45 respect to the preferred embodiment of exchanging 
email messages having file attachments. 
[0017] As is well known in the art. a person at a 
remote client device 24 may transmit an email message 
to a person who accesses email via the local server 12. 

50 The email message may be routed from ttie 
router/server 26 of ttie remote client device to the local 
server 12 via two communication links 20 and 28 to the 
network 22. The email message may be accessed by 
the target user using any of ttie supported client devices 

55 14. 16 and 18. 

[0018] In an Internet application of the system and 
method of exchanging email, tiie local and remote 
router/servers 12 and 26 are Internet Service Providers 
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(ISP8). It is not critical that the sending and receiving cli- 
ent devices subsaibe to different ISPs. That is* the 
method to be described below may be utilized to provide 
file-format conversion of an attachment to a message 
sent from one of the local client devices 14, 16 and 18 
to another one of the local client devices. 
[0019] The invention may also be used in a local area 
network or wide area network environment For exam- 
ple, the network 22 may be a corporate network of a sin- 
gle company having one or nrrore sites. 
[0020] One concern in the exchange of electronic 
messages, such as email, is that attachments may have 
access requirements that are not within the immediate 
capabilities of a receiving client device 14, 16 and 18. 
For example, access to a video file that is attached to an 
email message may have a file format that requires a 
receiving client device to have a specific application pro- 
gram, such as an MPEG player. If the receiving device 
does not include the necessary program, direct access 
is typically not possible. Thus, there is a possibility that 
the target user will not be able to display the attachment 
Many client devices have programs with the capability of 
converting attachments from a limited nunrriser of inac- 
cessible file formats to an acceptaksle file format. A word 
processing document n^y be efficiently converted. 
However, if the attached file is large, such as an intra- 
corporation multimedia presentation of a new product 
release, the conversion process is likely to be time con- 
suming. The process may dominate the resources of 
the client device, preventing a user from effidentiy utiliz- 
ing his or her time. 

[0021 1 The messaging system 10 of Rg. 1 provides an 
improvement over tiie conventional system by providing 
a format converter 30 at the server level. Consequently, 
if it is determined that a file attachment to an electronic 
message includes an attachment that cannot be 
accessed witiiout fQe-fbrmat conversion by the target 
client device 14, 16 and 1 8, the conversion process may 
be out-tasked to the format converter 30. If the determi- 
nation of the capabilities of tiie target client device 
occurs at the server level, the resources of tiie target 
device remain free during tiie entire process. That is. by 
providing a format check and a capability comparison at 
the local server 12. tiie process occurs while tiie target 
client device is off-line and the process is executed in a 
manner tiiat is transparent to the target device. In tiiis 
server-level emtxxiiment, an application register 34 is 
utilized by the local server to monitor the access capa- 
bilities of each client device, as will be explained more 
fully below. The client devices may be individually polled 
to determine which file formats are accessible without 
conversion. Alternatively, the client devices may be pro- 
grammed to provide updates regarding their capabili- 
ties. 

[0022] In another embodiment, tiie format check and 
the capability comparison occurs at the target client 
device 14, 16 and 18 at which tiie receiving party 
accesses the electronic message stored at the local 



server 12. If it is determined that the message attach- 
ment is inaccessible without conversion, a request is 
transmitted to the local server 12 to file-format convert 
tiie attachment at the converter 30. For example, a spe- 

5 dal protocol element P may be sent to request the con- 
version. Often, downloading an electronic message to a 
client device does not delete the storage of the mes- 
sage from the local server. For example, email senders 
based on tiie standard POPS (Post Office Protocol) 

w maintain a copy after download to a target client device. 
Thus, it is not necessary to upload the message to tiie 
local server 12 for conversion by tiie format converter 
30. 

[0023] If tiie format converter 30 of the local server 1 2 
15 is unable to convert tiie attached file, the message can 
be sent to the renrx^te router/server 26 from which tiie 
message was originally received. This may be neces- 
sary when tiie file format is unrecognized at tiie local 
server 12 and fomriat converter 30. As another possibil- 
20 ity, the format converter may not have the programming 
algoritiim for converting an attachment having a partic- 
ular file format 

[0024] In the emtxxiiment in which the compatibility 
comparison occurs at tiie client device level (rather tiian 

25 tiie server level), the special protocol element P that 
was originally generated at the target client device 14, 
1 6 and 1 8 may be forwarded from tiie local server 1 2 to 
the sending remote router/server 26 to request tiie nec- 
essary nmnipulation of tiie attachment that is not locally 

30 convertible. The remote router/server 26 is connected 
to a second format converter 32. If tiie second format 
converter is capable of placing tiie attachment in a file 
format tiiat is accessible by tiie target client device, tiie 
file format can be changed and the message can be 

35 retransmitted to the local server 12 for subsequent 
access by tiie target client device. On tiie other hand, if 
tiie remote conversion is not successful, tiie 
router/server 26 can return the message to tiie original 
client device 24. In some applications, the original client 

40 device may be automatically triggered to attenpt to 
locally convert tiie attachment. However, in typical appli- 
cations, the message to the originating client device 24 
is an informational message tiiat the target client device 
was unable to read tiie attachment, so that tiie attach- 
es ment should be resent in an accessible format. 

[0025] The protocol elements and messages 
described above can be designed and implemented in a 
manner in which they are buried in text format within the 
electronic message. Thus, any intermediary servers are 

50 unlikely to recognize tiie conversion requests. If the pro- 
tocol message is human readatste, it can anrive at the 
sender's message box of the remote router/server 26 
for subsequent viewing by tiie sender. 
[0026] In tiie embodiment of Rg. 1 . the client devices 

55 1 4, 1 6. 1 8 and 24 are shown as being computers. How- 
ever, tiiis is not critical. In the email application, the cli- 
ent devices may be any device that is used to access 
email, eitiier by means of wired transmission or wireless 
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transmission. 

[0027] The attachments to the messages may be sim- 
ple word processing documents. However, the Invention 
is more ben^icial If the conversion complexity and time 
consumption are greater than the complexity and time 
consumption typically associated with converting a 
word processing document For example, the attach- 
ment may be audio embedded into an email message, 
with the audio file requiring a specific player In other 
examples, the attachments may be video files or 
graphic files or a multimedia presentation. 
[0028] The application in which the format check of an 
attachment and the access-capability assessment 
occur at the server level will be described with reference 
to Figs. 1 and 2. In a f irst step 36. a f De is attached to an 
electronic message. In the preferred embodiment the 
message is an email message having a file attachment 
With reference to Rg. 1 , step 36 may be executed at the 
remote client device 24. 

[0029] In step 38, the electronic message is transmit- 
ted from the remote client device 24 to the local server 
12. At step 40. the local server receives the message 
and preferably stores the message in memory, using 
techniques well known in the art. For example, each 
subscriber of an ISP is assigned an email mailtx}x into 
which messages directed to the subscriber are stored. 
The mailbox system is carried out In software. A similar 
system is implemented within a corporate environment 
in which email and other electronic messages are 
exchanged within a corporate firewall. Thus, the mes- 
sage and attachment may be generated at one of the 
local client devices 14. 16 and 18 for access at another 
local client device. 

[0030] In step 42. the file format of the attachment is 
identified at the server level. In its simplest form, this 
may merely be a check of the file extension of the 
attachment. For example. .BMP identifies a bitmap 
graphics format and .MPEG identifies a specific video 
format As another format indicator, there may be an 
identifier that is intentionally embedded by the sending 
party within the message to indicate the file format of 
the attachment. As a third alternative, the server may 
attempt to access the attachment in order to klentify its 
file format. Other approaches to checking the file format 
may also be implemented. 

[0031 ] At step 44, the access capabilities of the target 
client device 14, 16 and 18 are determined. Referring to 
f^g. 1 . an application register 34 may be maintained at 
the server level. As is well known in the art, computers 
typically maintain an application register of programs 
stored at the computer. The application register 34 of 
Rg. 2 may be considered to be a universal application 
register that Identifies all of the access capabilities of 
various client devices that are used to access email 
stored at the local server 12. In one embodiment, the 
application register is maintained as a lookup table. 
When a client device is first used to access email stored 
at the local server, the client device Is polled to Identify 



its access capabilities. The polling process may also be 
used to periodically update a lookup table that is com- 
piled within memory of the server or within memory of 
an adjunct device. While the format converter 30 and 

5 the application register 34 are shown as being con- 
nected to the local server 12. the operations of the con- 
verter and register may be integrated into known 
servers. As an alternative to the polling approach, the 
client devices 14, 16 and 18 may be programmed to 

w identify their Individual access capabilities each time 
that a program is upgraded or added to the client 
device. 

[0032] At step 46, it is detennined whether the attach- 
ment is accessible at the target client device without 

75 conversion. If the attachment is accessible without con- 
version, the message is transmitted to the target client 
at step 48. This transmission is a conventional down- 
load step and its execution is not critical to the invention. 
Optionally, if it Is determined that the attachment is inac- 

20 cesslble without conversion, the message may never- 
theless be transmitted to the client, if there is a 
determination that the conversion is neither complex nor 
time consuming. For example, a short word processing 
document may be forwarded to the target dient device 

25 despite a conversion requirement 

[0033] If at step 46 it is determined that there is an 
incompatibiiity between the access requirements of the 
attachment and the direct access capabilities of the tar- 
get client device, the process proceeds to step 50 for a 

30 determination of whether the attachment is locally con- 
vertible. If the attachment is locally convertible, the f Ue- 
format change is implemented at step 52 and the mes- 
sage is made accessible to the target client device at 
step 48. Preferably, the checking steps 42 and 44. the 

35 determining steps 46 and 50. and the conversion step 
52 are inplemented without intervention by the target 
client device Thus, the process occurs "off-line" with 
respect to the target client device. This frees the client 
device to operate in other capacities. 

40 [0034] The file format conversion at step 52 is exe- 
cuted using known techniques. Conventionally, compu- 
ter software is utilized to change an attachment from 
one ffle format to another. However, if the format con- 
verter 30 of Fig. 1 1s incapable of providing the conver- 

45 sion. because the file fomiat is unrecognizable or 
because the format converter is not programmed to pro- 
vide a particular conversion, the conclusion at step 52 is 
that the attachment is not locally convertible. In this sit- 
uation, a request is generated and transmitted from the 

50 local server 12 to the sending remote router/server 26. 
The request includes instructions to convert the attach- 
ment to an accessible file format For example, at step 
54, a special protocol element P may be generated and 
transmitted to the remote server to determine whether 

55 the remote format converter 32 has capabilities beyond 
that of the local system. Ideally, at step 56. the attach- 
ment is reformatted remotely and the local server 12 
receives the message with a converted attachment. 
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which is made available to the target client device at 
step 46. However, if neither the local system nor the 
remote system is capable of providing an accessible 
attachment, the protocol message may be fonA^arded to 
the originating dient device 24. As previously noted, the 
forwarded protocol message may be used merely to 
inform the sending party that the attachment was not 
received and displayed at a client device. AKernatively. 
the protocol message may be formatted to trigger an 
automatic conversion and retransmission of the attach- 
ment in an alternative file format. 
[0035] Reference will be made to Figs. 1 and 3 in 
describing the embodiment in which the format check 
and the access-capability determination occur at the 
target client device 14. 16 and 18. Steps 36. 38 and 40 
are identicat to the process described with reference to 
Rg. 2. Thus, a f Oe is attached to a message at a sending 
client device 24 and the message is received at the local 
server 12. The message Is stored for access by the user 
at one of the local client devices 14. 16 and 18. When 
access is requested, the message is transmitted to the 
client device at step 58. 

[0036] A file format check occurs at the target client 
device in step 60. Some of the possible approaches to 
perfomiing the check were described with reference to 
step 42 in Rg. 2. For example, the format check may 
merely be an identification of the file extensicm. 
[0037] After the file format has been identified, in step 
62 it is determined whether the attachment is directly 
accessible, i.e., whether the attachment is accessible 
without conversion. If the attachment is directly accessi- 
ble, the file is displayed at step 64. On the other hand, a 
determination that the attachment is inaccessible with- 
out conversion triggers a transmission of a request to 
the local server 12 at step 66. The request may be the 
above-identified protocol element P. The request 
includes instructions to convert the attachment to a par- 
ticular accessible file format. 
[0038] In the determination step 68. the ability of per- 
forming the requested manipulation at the fbrniat con- 
verter 30 is ascertained. If the ability exists, the process 
is inplemented at step 70. Preferably, the message and 
attachment remain stored at the local server, so that the 
conversion can take place without an upload of the mes- 
sage from the target client device to the local server. 
Following the file-format change at step 70. the mes- 
sage is again accessible to the client device at step 72. 
but with the attachment in a directly accessible file for- 
mat. 

[0039] Returning to the determination step 68. a neg- 
ative response to the capability of executing a local con- 
version wilt trigger a transmission of a request to the 
remote router/server 26 from which the message was 
received. This is shown at step 74. If the remote format 
converter 32 is capable of performing the requested 
refonnatting operation, the reformatted attachment is 
transmitted to the local server 12 at step 76. The refor- 
matted attachment may then be transmitted to the tar- 



get client device at step 72 for display at step 64. On the 
other hand, if the reformatting operation cannot be exe- 
cuted, the request is fonwarded to the originating client 
device 24. As previously noted, this request may merely 

5 be informational or may be used to automatically trigger 
a desired operation at the remote client device, such as 
a reformatting operation. The protocol message can be 
designed in a way that the protocol element P is buried 
in text format in an email message that is human reada- 

10 ble, so that intermediary servers do not recognize the 
conversion request as the request is forwarded to the 
sender's server. 

[0040] While the invention has been desaibed prima- 
rily with respect to email transmissions, this is not aiti- 

is cal. The system and method nnay be used in other 
applications. Moreover, it is anticipated that servers will 
be dedicated to the attachment conversion. \Neb sites 
may also performs these functions, so that unresolved 
requests for conversion may be sent to a conversion 

so service that is outskJe of the sender-to-receiver trans- 
mission path. That is. the format converter 30 may be 
maintained by a private company that provides service 
to subscribing companies or individuals. 

2S Claims 

1 . A method of providing message exchange capabil- 
ity for a plurality of users comprising steps of: 

30 receiving electronic messages at a server that 

supports message access by said users, 
including receiving first electronic messages 
having attachments in file formats that are each 
specific to one of a plurality of applications; 

35 identifying capabilities of client devices with 

respect to accessing said attachments without 
conversion from an original f De format to a sec- 
ond file format; 

determining whether said attachments are 
40 accessible without conversion by specific client 

devices to which said attachments are trans- 
ferred; 

converting first attachments from original file 
formats to selected second file formats at said 
45 server in response to determinations that said 

first attachments of said first electronic mes- 
sages are inaccessitsle without conversion by 
said specific client devices to which said first 
attachments are transferred, including select- 
so ing said second file formats based upon said 
capabilities of said specific client devices; and 
selectively transferring said electronic mes- 
sages to said dient devices, including transfer- 
ring said first attachments to said specific dient 
55 devices in said selected second file forn^ts. 

2. The method of claim 1 wherein said step of identify- 
ing said capabilities of said client devices indudes 
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maintaining a register off applications at said server, 
said register having data indicative of application 
progranfis that are stored at Individual client 
devices. 

3. The metliod of claim 1 wherein said step of deter- 
mining whether said attachments are accessible 
without conversion includes comparing application 
requirements of eadh said attachment to said capa- 
bilities of said specific client devices to which said 
attachments are transferred, said step of compar- 
ing being implemented at said server such that said 
step of converting is executed prior to said first 
attachments being transferred. 

4. The method of claim 1 wherein said step of identify- 
ing said capabilities of said client devices includes 
maintaining a register of applications at each client 
device, each register having data Indicative of appli- 
cation programs stored at said client deynce at 
which said register is maintained, said step of 
determining whetiier said attachments are accessi- 
ble witiiout conversion being executed at said client 
devices. 

5. The mettiod of claim 4 further comprising a step of 
transmitting a client-to-server message from a first 
client device to said server in response to determin- 
ing that an attachment of one of said first electronic 
messages is inaccessible by said first client device 
without conversion, said message being a request 
to convert said attachment at said sender. 

6. The method of claim 1 further conrprising a step of 
determining whetiier said server has a capability of 
converting said attachments to file formats that are 
accessible by said specific client devices to which 
said attachments are transferred, said method fur- 
ther conrprising a step of generating and transmit- 
ting a request to a remote server from which a 
particular electronic message was received as a 
response to determining that said particular elec- 
tronic message includes an attachment which said 
server Is incapak)le of converting to a file format that 
is accessible by a client device to which said partic- 
ular electronic message is to be transferred, said 
request including instructions to convert said 
attachment at said renfx>te server to an accessible 
file format, said electronic messages being email 
messages. 

7. The method of claim 6 further comprising transmit- 
ting a second request from said remote server to a 
remote client device at which said particular elec- 
tronic message was generated in response to 
determining that said remote server is incapable of 
converting said particular electronic message to 
said accessible file format sard second request 



including Instructions to retransmit said attachment 
in an accessible file fomnat. 

8. The method of claim 1 wherein said step of deter- 
5 mining whether said attachments are accessible 

witiiout conversion includes accessing text informa- 
tion of said first electronic messages, said text infor- 
mation being indicative of said original file formats 
of said first electronic messages. 

10 

9. The mettiod of claim 1 wherein said step of receiv- 
ing said first electronic messages includes receiv- 
ing said attachments in video and graphics file 
formats, said first electronic messages being email 

75 messages. 

10. The method of claim 9 wherein said step of receiv- 
ing said first electronic messages includes receiv- 
ing said attachments in audio file formats, said first 

20 electronic messages being email messages. 

11 . A method of accessing email attachments compris- 
ing steps of: 

25 receiving an email message at a local server, 

said email message having an attachment hav- 
ing an original application-specific file format; 
comparing access requirements of said attach- 
ment in sak:! application-specific file format to 

30 format capabilities of a client device to which 

said email message is directed for access by a 
user, said format capabilities being indicative of 
an ability to access said attachment in said 
original application-specific file format; 

35 converting said attachment to a second appli- 

cation-specific fOe format in response to deter- 
mining tiiat said attachment is inaccessible at 
said client device while in said original applica- 
tion-specific file format, said converting being 

40 Implemented at a site remote from said client 

device; and 

transferring said attachment in said second 
application-specific f Oe format from said local 
server to said client device. 

45 

12. The method of claim 11 wherein said step of com- 
paring said access requirements to said format 
capabilities is executed at said local server and 
includes maintaining a register of applications at 

50 said local server, said register having data indica- 
tive of said format capabilities of said client device. 

13. The method of claim 1 1 wherein said step of com- 
paring said access requirements to said format 

55 capabilities is executed at said client device, said 
method further comprising transmitting a message 
to said local server to request said conversion of 
said attachment by said local server when it is 
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determined that said attachment is Inaccessible t>y 
said client device wrthcxit said conversion. 



server lacks resources for converting said particular 
first attachment to said selected second file format. 



14. The method of claim 13 further comprising trans- 
mitting a second message to a remote server to s 
request said conversion of said attachment by said 
remote server when H is determined that said local 
server is incapable of said conversion. 

1 5. The method of daim 1 1 wherein said step of receiv- io 
ing said attachment is a step of receiving a video or 
graphics file. 

16. The method of claim 1 1 wherein said step of com- 
paring said access requirements to said file capa- 75 
bilities and said step of converting said attachment 
are implemented such that said client device is free 

to execute other tasks during said converting. 

1 7. An email delivery system comprising: 20 

a local email server connected to a network to 
receive enroll messages, including first email 
messages having attachments in original file 
formats that are each specific to one of a plural- 2S 
ity of applications, said local email server hav- 
ing memory for staing said email messages; 
a plurality of client devices connected to said 
local email server to selectively access said 
email messages; 3o 
register means for identifying first attachments 
that are inaccessible by a specific one of said 
client devices in an absence of converting said 
first attachments from said original file format, 
said first attachments being attachments of 35 
said first email messages, said register means 
being connected to one of said local email 
server and said plurality of client devices; and 
converter means responsive to said register 
means and located at said local email server 40 
for converting each said first attachment to a 
second file format that is selected to accommo- 
date access without conversion by said specific 
one of said client devices. 

45 

18. The system of claim 17 wherein said register 
means is a register stored at said local email server, 
said register having data indicative of applications 
that are stored at each one of said client devices. 

so 

19. The system of daim 18 wherein said converter 
means is a conversion program stored in said mem- 
ory of said local email sender. 

20. The system of claim 19 further comprising means ss 
for transmitting a request to a remote sender to con- 
vert a particular one of said first attachments in 
response to a determination that said local email 
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